終於寫到最後一篇了，從 JDK 內建的 HttpServer 一路到最後的 Todo API，中間好幾次覺得自己是不是題目開太大，結果只寫了 32 篇 (也是因為後來捨棄了一些東西沒有寫)，上一個 Kotlin Lambda 系列 還寫了 36 篇 XD

會挑這個題目的原因 day 01 講過了，這裡就不重複，簡單來說就是想搞懂 routing {}、install(...)、receive<T>() 這些寫法背後到底在幹嘛

真的動手做一次才發現，原本想的「照著做一遍應該還好」，跟實際寫下去完全是兩回事，Routing 看起來就是「路徑對到函式」而已，可是 404 / 405 / trailing slash / HEAD fallback 這些自己處理過一遍，才知道裡面有多少事情要做決定，Pipeline 也是，講起來就是一串 middleware 疊在一起，實際寫下去是 foldRight 組洋蔥，後面還得再升一次 suspend

我覺得寫過了一次，大概知道重點是那些，以後在專案裡用 Ktor，遇到某個行為跟想的不一樣，腦中還有個模糊的印象，知道「這個好像跟哪件事有關」，再回來翻自己寫過的文章就好 (或是看原始碼)，文章都是寫給未來的自己看的

手刻完再回頭看 Ktor

我們的 middleware 就是一串函式包一串函式，加進去的順序決定包起來的順序，Ktor 那邊是 phase-based pipeline，middleware 要先講清楚自己掛在哪個 phase，phase 之間還可以再插新的，兩邊解決的是同一件事，但 Ktor 多解了一個我們用「你自己顧好 install 順序」帶過的問題，plugin 是各自獨立安裝的，彼此不知道對方存在，總要有個辦法決定誰先誰後

手刻過之後再去翻 Ktor 原始碼，不再是一片模糊，看到 Pipeline.kt 至少知道它在處理什麼，看到 ApplicationReceiveFunctions.kt 也會想到自己那個 receive<T>() 是怎麼長出來的

但也不是全部看懂，phase 的合併規則、多 engine 的抽象、那些 attribute key 傳來傳去的地方，還是另一個量級，而且這樣比其實也不太公平，Relix 是為了文章寫出來的，很多情況我們直接不處理就算了，Ktor 得面對真的有人拿它跑 production

回頭看 TDD 的呈現方式

day 01 就先講過，這個系列雖然是用 TDD 寫的，但不走 baby step，而是把測試案例集中放在每篇前面，看完再進實作

32 篇寫完，好處跟前一個系列一樣，文章乾淨很多，一次看完這個功能該有的行為和邊界條件，代價也一樣，中間那些失敗和修正的過程你都看不到

不過這個系列比前一個系列多一層，連測試工具本身都是長出來的，TestKit 從 day 06 一個最陽春的版本開始，day 11 讓它支援 routing DSL，day 14 升級成 suspend，day 20 補上 JSON 驗證，day 28 才收斂成 relixTest { }。所以測試的寫法一路都在變，同一件事在 day 10 和 day 30 長得不太一樣

整個的好處是「工具跟著框架一起演進」這件事本身就是內容，測試工具不會憑空出現，它也是被需求推出來的，代價是跳著看的讀者很可能覺得前後不一致，明明是同一個系列，怎麼每隔幾篇測試就換一種寫法

今年很特別，鐵人賽一次寫了兩個主題，也把自己搞得很累，前前後後花在文章和範例上的時間比想像中多很多，明年應該不會再這樣搞自己了，乖乖寫一個主題就好，另外，原本今年是想寫 KMP (Kotlin Multiplatform) 的，不過今年剛好有用到 Ktor，想說就先寫 Ktor 好了，明年沒意外的話，應該就會輪到 KMP 吧 XD

更新，其實在 手刻 Ktor 從零開始 連載到一半時，又手殘開了一個 Ktor 實戰 101 的主題，所以今年寫了三個主題，然後因為新工作的關係，明年有可能會是 Rust 的主題，而不是 KMP XD

同步刊登於 Blog

圖片來源：AI 產生